Did you specifically need a ethernet version? Seems like some version of --with-mpi* would be more useful?

I tried building GA a while back, but I used it's CMake component. I ended up with a libcomex.a library, without specifying any particular flags for this.

just tested, without any armci related options, it defaults to this

--with-mpi-ts select armci network as (Comex) MPI-1 two-sided

and effectively there's a libcomex.a built

that provides an interface with the used MPI library? dropping the interconnect specification at the GA level ?

@Micket I upgraded the ebs by using --with-mpi-ts for GA, OpenMolcas is built fine on it, and a test job I was provided runs fine in an infiniband and another ethernet cluster.

@Micket I created the patches for GA based on the pull requests upstream you mentioned,
GlobalArrays/ga#101
and
GlobalArrays/ga#122

I added another small patch for OpenMolcas, as one script triggered during the installation, will try to force a copy of the pymolcas executable in some place on the local home folder of the user doing the install.
That's quite weird anyway, as the make install already takes care of installing it in the prefix folder, which is where it should stay in our case.
I don't get why they force that extra copy, the patch avoids that.

The build of both things goes on fine, and a small test job i was given runs fine.

i don't get why i got only this time the error during Travis Checks

AssertionError: '-Python-%(pyver)s' included in versionsuffix in OpenMolcas-18.09-intel-2018b.eb

despite the dep was always there before.

fixed in latest commit.

@arielzn We enhance the checks done in Travis from time to time, and for some things we only enforce them in easyconfigs being added/touched.
For this particular check, see https://github.com/easybuilders/easybuild-easyconfigs/pull/7754/files .

@Micket that was what you requested , right ?
adding the options and updating this PR to force checks ?

@arielzn I got really busy last week. If you could do a eb --upload-test-report --from-pr 7699 --rebuild that would be great (I would do it myself, but my 2018b tree is a bit broken from some earlier experiments with python).

some bad news, when enabling those options for GA, I get errors when building OpenMolcas afterwards (GA finished fine).

The OpenMolcas errors are as these:

/home/ulg/xxxxxxxxxxx/.local/easybuild/software/GlobalArrays/5.7-intel-2018b/lib/libga.a(ga_diag.o): In function `gai_diag_std_':
ga_diag.F:(.text+0x7d5): undefined reference to `fmemreq_'
ga_diag.F:(.text+0x969): undefined reference to `pdspev_'
/home/ulg/xxxxxxx/.local/easybuild/software/GlobalArrays/5.7-intel-2018b/lib/libga.a(ga_diag.o): In function `gai_diag_':
ga_diag.F:(.text+0x15e6): undefined reference to `fmemreq_'
ga_diag.F:(.text+0x17a7): undefined reference to `pdspgv_'
/home/ulg/xxxxxxxxx/.local/easybuild/software/GlobalArrays/5.7-intel-2018b/lib/libga.a(ga_diag.o): In function `gai_diag_reuse_':
ga_diag.F:(.text+0x265e): undefined reference to `fmemreq_'
ga_diag.F:(.text+0x2814): undefined reference to `pdspgv_'
/home/ulg/xxxxxxxxx/.local/easybuild/software/GlobalArrays/5.7-intel-2018b/lib/libga.a(ga_diag.o): In function `gai_diag_std_':
ga_diag.F:(.text+0x7d5): undefined reference to `fmemreq_'
ga_diag.F:(.text+0x969): undefined reference to `pdspev_'
/home/ulg/xxxxxxxx/.local/easybuild/software/GlobalArrays/5.7-intel-2018b/lib/libga.a(ga_diag.o): In function `gai_diag_':
ga_diag.F:(.text+0x15e6): undefined reference to `fmemreq_'
ga_diag.F:(.text+0x17a7): undefined reference to `pdspgv_'
/home/ulg/xxxxxxx/.local/easybuild/software/GlobalArrays/5.7-intel-2018b/lib/libga.a(ga_diag.o): In function `gai_diag_reuse_':
ga_diag.F:(.text+0x265e): undefined reference to `fmemreq_'
ga_diag.F:(.text+0x2814): undefined reference to `pdspgv_'
make[2]: *** [bin/casvb.exe] Error 1
make[2]: Leaving directory `/home/users/xxxxxx/.local/easybuild/build/OpenMolcas/18.09/intel-2018b-Python-3.6.6/easybuild_obj'
make[1]: *** [CMakeFiles/casvb.exe.dir/all] Error 2

If I remove those NWChem options and rebuild GA, OpenMolcas builds fine.

any idea of what could be causing that?

The option to blame seems to be --enable-peigs on GA

When using that is required to build something else as prereq ?

I can't find detailed info about that PeIGS library.

@arielzn I looked into it, and it seems the parallel eig function in GlobalArrays expects the user to link in external symbols. NWChem implements these functions;
https://svn.pnl.gov/svn/nwchem/trunk/src/peigs/src/c/memreq_f.c

GA should have kept this addition as a separate library, so that normal users can link to just what they need, but.. they didn't. Pretty horrid design choices all around here I would say.

Our options are

1. Create a separate GA-config for NWChem with a "-peigs" suffix.
2. Make OpenMOLCAS statically link (as it's not using these functions, the linker wont require the symbols it uses).
3. Patch OpenMOLCAS to add these symbols (could just be empty placeholders, so not really such an impossible task, but, very ugly)

Option 1 would mean that there are incompatible.. but, perhaps that's just what we need. It would also allow users to pick. Still though, very annoying, as this could have been so very easily avoided by GA.

Some info about
GlobalArrays/ga#96

I'm not sure then if we can have a GA version compatible with NWChem and OpenMolcas at the same time.

Just saw your message after my last comment.

We could try 2. I'm not sure how these things were handled in other cases, if something equivalent happened before.

I'm not sure then if we can have a GA version compatible with NWChem and OpenMolcas at the same time.

I think we could with if OpenMolcas statically linked. It's never going to call peigs().

It doesn't really build anything different; it just replaces the functionality with a dummy function (with no external deps) if you don't enable it:
https://github.com/GlobalArrays/ga/blob/1537981033d7b2e5cbeeaaf40529fbf4d414724a/global/src/peigstubs.c#L33

Question is, what is the least ugly solution? Probably just having 2 GA's and add -peigs suffix

Question is, what is the least ugly solution? Probably just having 2 GA's and add -peigs suffix

probably that will be the most explicit and cleaner solution, in case some other package is going ever to be built against GA

probably that will be the more explicit and cleaner solution, in case some other package is going ever to be built against GA

Yes. Just drop the extra flags, I will be making a new PR for 2019a with a -peigs version

Test report by @arielzn
SUCCESS
Build succeeded for 2 out of 2 (2 easyconfigs in this PR)
dragon2-ctrl0.umons.ac.be - Linux centos linux 7.6.1810, Intel(R) Xeon(R) Gold 6130 CPU @ 2.10GHz, Python 2.7.5
See https://gist.github.com/d26ec8474363048eefc2e9dbe97fded7 for a full test report.

Going in, thanks @arielzn!